Data processing system

ABSTRACT

A technique for manipulating objects at a computer is described. The technique includes receiving one or more requests to manipulate an object, wherein each request is received from a different thread. Each request to manipulate an object generates a copy of the object and a unique identifier for each copy of the object. A request to manipulate a copy of an object is distinguished from other requests to manipulate other copies of the object using the unique identifier.  
     Additionally, a technique for accessing objects at a computer is described. The technique includes receiving a request from a client process for an object which is stored in an object server. A library server process is allocated to handle the object request. Transfer of the requested object is initiated. Thereafter, the library server process that was allocated to the object request is released.

PROVISIONAL APPLICATION

[0001] This application claims the benefit of U.S. ProvisionalApplication No. 60/162,700, entitled “DATA PROCESSING SYSTEM,” filed onOct. 29, 1999, by Donald E. Benson et al., attorney's reference numberST9-99-156, which is incorporated by reference herein.

BACKGROUND OF THE INVENTION

[0002] 1. Field of the Invention

[0003] This invention relates in general to database management systemsperformed by computers, and, in particular, to processing objects.

[0004] 2. Description of Related Art

[0005] For nearly half a century, computers have been used extensivelyby businesses to manage information such as numbers and text, mainly inthe form of structured, digital coded data. For example, digital datahas been used with airline ticket reservations, bank deposits, insuranceclaims, and credit card transactions. The average size of business datain digital form is relatively small. For example, a banking recordincluding a customer's name, address, phone number, account number,balance, etc. represents approximately a few hundred characters or a fewhundreds or thousands of bits.

[0006] Business data, however, represents only a small part of theworld's information. With advances in storage, communication, andinformation processing technologies, other forms of digital dataincluding images, audio, and video have been combined with traditionaltext and numeric information to form new types of information—multimediainformation. Multimedia information is different from general businessdata since it cannot be fully pre-structured (its use is not fullypredictable), and because it is the result of the creation of a humanbeing or the digitization of an object of the real world (e.g., x-rays,geophysical mapping, etc.) rather than a computer algorithm. Inaddition, the average size of multimedia information may besignificantly larger than digital business data.

[0007] Numerous applications utilize libraries of digitized data, i.e.,digital libraries. For example, digital works are widely used with theInternet, tweening (i.e., identifying animation objects and definingtheir movements), WebTV, Synchronized Multimedia Integration Language(SMIL) (enabling Web developers to divide multimedia content intoseparate streams, send them to a user, and have the streams appear as asingle multimedia stream), and other network applications based onTransmission Control Protocol/Internet Protocol (TCP/IP) communicationsand similar communications protocols. As these technologies advance andtheir costs come down, it becomes more feasible to digitize other typesof data, store large volumes of it, and be able to distribute it ondemand to users at their place of business or home. However, the speedat which multimedia applications execute may be limited by having tomanipulate copies of the same object called for by the applications insequential order.

[0008] At any one time, access to an object in a multimedia database maybe limited to a single client or a single work flow application orprocess. This is true even though the application may need multiplecopies of the same object (e.g., copies for memory, for file in a datastore, and for application). This sequential processing scheme is theresult of a number of fundamental processing limitations.

[0009] When multiple copies of an object are being downloadedsimultaneously to a single receiving system over a network or other dataline, the receiving system may not be able to distinguish between themultiple copies of the same object. For example, User A requests anobject and downloads Copy 1 of the object. User B simultaneouslyrequests that same object and receives Copy 2 of the object. Copy 1 andCopy 2 may be downloaded such that a portion of Copy 1 is transmittedover the network, then a portion of Copy 2 is transmitted, etc.Therefore, it is necessary to be able to distinguish between copies ofthe same object.

[0010] A second limitation is that an application program can notdistinguish a copy of an object from the original object. For example,User A may download a copy of an object from memory, modify that copy,and upload the copy to back to memory, which also stores the originalobject. User B may then request a copy of the original object. User B,however, can not distinguish a copy of the object from the originalobject, and thus, User B may retrieve either the original object or thecopy modified by User A. Consequently, User B may download the copy ofthe object modified by User A instead of downloading the originalobject. Thus, it is necessary to be able to distinguish between anobject and a copy of an object.

[0011] A third limitation is that an application may have multipleapplication threads (i.e., units of work within an application), andeach application thread may request different copies of an object, butthese retrieve requests cannot be distinguished in conventional systems.Thus, the application can not track which threads have processedparticular copies of an object. Even if the application knows that oneof the object copies has downloaded, the application will not know whichthread the copy is for. Thus, since applications can not track thecopies, they can not track when threads have finished manipulatingparticular copies of objects.

[0012] In conventional systems, users and applications receive andprocess objects sequentially. Consequently, users experience processingdelays with the sequential processing system. This problem is amplifiedwhen users execute multithreading applications or applications arerequired to manipulate large objects and/or numerous objects. Forexample, the Internet may produce thousands or tens of thousands ofcopies of the same object. In addition, programs utilizing multiplecopies of a single object are more complicated since programmers must becareful to design the program such that all the threads run withoutinterfering with each other. As a result, programs are slower, createunnecessary user inconvenience, and more expensive since programmersmust expend extra time and effort to overcome these shortcomings.

[0013] Therefore, there is a need in the art to uniquely identify eachrequest to retrieve or store an object to enable multiple users tosimultaneously manipulate copies of the same object.

[0014] In addition, conventional system process requests for objects byallocating a child process of a library server to process the requestsuch that library server loses control over the child process while theobject request is being retrieved. As a result, the child process cannot be allocated to another object request until the object has beencompletely transferred from the object server. More specifically, therequest for an object comes from a client server to the daemon processassociated with the client server. The request is then transferred fromthe daemon process to the library server. Then, the request istransferred from the library server to the object server. The objectserver begins to transfer the object to the client computer via thedaemon. After the entire object has been transferred to the clientcomputer, the daemon process notifies the object server that thetransfer is complete. The object server then notifies the library serverwhich in turn notifies the daemon process that the transfer is complete.Finally, control of the child process that was allocated to the objectrequest is restored to the library server such that the child processmay serve other client requests.

[0015] Conventional object retrieval systems have a number ofshortcomings. The child process can not handle subsequent tasks untilthe first transfer is completed and the object server releases the childprocess of the library server. Only then can the child process beallocated to handle a second object request. Furthermore, a user doesnot regain control over the object transfer until the object has beentransferred and the child process is released. Consequently, each childprocess processes requests in a synchronous manner in the order in whichthey are received. As a result, the child process is allocated and idlewhile the object is being transferred. Moreover, the abilities of a userare restricted until the object is transferred and the child process isreleased. Thus, conventional systems do not utilize resources in anefficient manner resulting in diminished throughput, performance, anduser interaction and control. These shortcomings are further amplifiedif large objects or a large number of objects are requested since the achild process will be allocated and idle for a longer period time toprocess these requests.

[0016] Accordingly, there is a need in the art to release processresources before a time when an object has been completely transferredsuch that process resources may be allocated to different tasks duringthe object transfer and such that a user may perform more tasks duringthe object transfer.

SUMMARY OF THE INVENTION

[0017] To overcome the limitations in the prior art described above, andto overcome other limitations that will become apparent upon reading andunderstanding the present specification, the invention discloses amethod, apparatus, and article of manufacture for uniquely identifyingrequests to retrieve or store an object.

[0018] According to one embodiment of the invention, one or morerequests are received to manipulate an object. Each request is receivedfrom a different thread. For each object request, a copy of the objectis generated and a unique identifier is associated with the request andthe object copy. Requests to manipulate copies of the same object aredistinguished using the unique identifier.

[0019] According to another embodiment of the present invention, arequest for an object stored in an object server is received from aclient process. A library server process is allocated to the objectrequest. Under control of the library server process, transfer of therequested object from the object server is initiated. After initiatingthe transfer, the library server process is released.

BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Referring now to the drawings in which like reference numbersrepresent corresponding parts throughout:

[0021] FIGS. 1(A-C) schematically illustrate the hardware environment apreferred embodiment of the present invention, and more particularly,illustrates a typical network system with a digital library server.

[0022]FIG. 2 is a block diagram illustrating a memory configuration of aclient computer and a daemon process utilized by the objectidentification system.

[0023]FIG. 3 is a flow diagram illustrating the technique used by theobject identification system to manipulate (store or retrieve) one ormore objects.

[0024]FIG. 4 is a flow diagram illustrating the steps performed by theobject identification system to populate elements which are referencedby element handles with object data.

[0025]FIG. 5 is a flow diagram illustrating the steps performed by theobject identification system to store an object in an object server.

[0026]FIG. 6 is a flow diagram illustrating the steps performed by theobject identification system to retrieve an object from an objectserver.

[0027]FIG. 7 is a flow diagram illustrating the steps performed by theobject identification system to remove an element, element handle, andrelated object data from an element table.

[0028]FIG. 8 is a flow diagram illustrating the technique used by theobject access system.

DETAILED DESCRIPTION

[0029] In the following description of embodiments of the invention,reference is made to the accompanying drawings which form a part hereof,and in which is shown by way of illustration specific embodiments inwhich the invention may be practiced. It is to be understood that otherembodiments may be utilized and structural and functional changes may bemade without departing from the scope of the present invention.

Overview

[0030] This invention addresses multiple requests to manipulate (i.e.,store or retrieve) an object. In particular, each request to store orretrieve an object is assigned a unique identifier. This enablesdistinguishing object copies from each other and distinguishing objectcopies from the original object.

[0031] The unique identifier is an element handle. An element handlerefers to a memory address allocated to each individual storage orretrieval request submitted by threads of an application process. Aprocess is an executing program, and a thread is a unit of work of theprocess. A user submits the request to manipulate an object to a clientcomputer. The client computer generates the element handle. The clientcomputer transfers the element handle to a library server. The libraryserver locates which one of a plurality of object servers stores or willstore the object and selects that object server. The library serverpasses the element handle to the selected object server. The objectserver receives the element handle and communicates with the clientcomputer to execute the user's request. This triangular communicationsystem among the client, library, and object servers ensures that allservers have the element handle. With the element handle, each serverknows the source of every request for an object. In addition, eachserver knows which request corresponds to a particular object or copy ofan object. Thus, when an object is requested by multiple threads, eachthread may simultaneously execute with copies of the same object basedon the unique identifier.

[0032] The present invention also addresses retrieving objects fromobject servers asynchronously such that a child process of a libraryserver is released after the object transfer is initiated. Inparticular, instead of waiting until a whole object has been transferreduntil a child process of a corresponding library server is released, thechild process is released before the object transfer has been completedto enable the child process to attend to other tasks.

Hardware Environment

[0033] FIGS. 1(A-C) schematically illustrate a preferred embodiment ofthe hardware environment that may be used with the present invention.More particularly, FIG. 1A illustrates atypical distributed computersystem in which a user utilizes a network 100 to connect clientcomputers 110. The client computers 110 execute applications utilizing adigital library server 120 and related object servers 130. A typicalcombination of resources may include client computers 110 that arepersonal computers or workstations, and a library server 120 that is apersonal computer, workstation, minicomputer, or mainframe. An objectserver 130 may comprise, for example, a multimedia database. Thesesystems are coupled to one another by various networks 100, includingLANs, WANs, SNA networks, and the Internet.

[0034] A client computer or server 110 typically executes a clientapplication and is coupled to a library computer or server 120 executingserver software. The client application is typically a software programsuch as a workflow application. The server software is typically aprogram such as IBM's Digital Library or Visual Info server software.The library server 120 also uses a data source interface and, possibly,other computer programs, for connecting to the object servers 130. Theclient computer 110 is bidirectionally coupled with the both the libraryserver computer 120 and the object servers 130 over a line or via awireless system. In turn, the library server computer 120 is alsobidirectionally coupled with the object servers 130.

[0035] The object server 130 interface may be connected to a DatabaseManagement System (DBMS), which supports access to an object server 130by executing Relational Database Management System (RDBMS) software. Theinterface and DBMS may be located on the same server as the libraryserver computer 120 or may be located on a separate machine. Inaddition, the object servers 130 may be geographically distributed.Programs, including an object identification system 140 and the objectretrieval system 150 may be resident and execute within the clientcomputer 110, library server 120, and object servers 130. The objectidentification system 140 and the object retrieval system 150 manage theactivities of each server and manages the communications betweenservers.

[0036] Both the object identification system 140 and object accesssystem 150 request that the client computer 110, library server 120, andobject servers 130 perform specific tasks to execute each request tomanipulate an object. When the following sections refer to a serverperforming a certain task, these actions are considered to be initiatedand managed by the object identification system 140 or object accesssystem 150 resident on each server involved in completing the task.However, in order to provide a detailed explanation of the presentinvention, the specification will refer to the actual component (e.g.,client computer 110, library server 120, and object server 130) asperforming a specific manipulation or retrieval task rather than theobject identification system 140 or object access system 150 even thoughthese systems may coordinate the activities of each component.

[0037] Those skilled in the art will recognize that the exemplaryenvironment illustrated in FIG. 1A is not intended to limit the presentinvention. Indeed, those skilled in the art will recognized that otheralternative system environments may be used without departing from thescope of the present invention.

[0038]FIGS. 1B and 1C, block diagrams illustrating the communicationsamong the servers and computers, illustrate a client computer 110, alibrary server 120, and one or a plurality of object servers 130utilized by the object identification system 140 and object accesssystem 150. A user communicates with the client computer 110 and submitsa request to the client computer 110 to manipulate (i.e., to store orretrieve) a particular object. The request may be generated by the user,through an application program interface (API) resident on the clientcomputer 110, by clicking an icon which launches an application. Inorder to retrieve an object . . . In order for the application programto execute, the application process may need to execute various processthreads. Each thread may have to manipulate an object, possible theretrieved object or possibly the same object as other threads. Theclient computer 110 generates a unique identifier for each element orset of data generated for each request to enable each thread tosimultaneously execute, even if those threads request the same object.

Multiple, Concurrent Store/Retrieve of Same Objects

[0039]FIG. 2, a flow diagram of the technique utilized by the objectidentification system 140, generally illustrates how requests to storeor retrieve objects are assigned unique identifiers and how thoserequests are executed utilizing a client computer 110, library server120, and data stores or object servers 130. Initially, in block 200, theobject identification system 140 receives a request to manipulate anobject. Then, in block 210, the object identification system 140generates a unique identifier or element handle. The objectidentification system 140 populates an element referenced by the elementhandle with related object data in block 220. In block 230, the objectidentification system 140 transfers the element handle to a libraryserver 120. The object identification system 140 then transfers theelement handle to an object server 130 selected by the library server120 in block 240. In block 250, if the user request is to store anobject, then the object identification system 140 executes the requestto store an object. After storing the object, in block 260, the objectidentification system 140 updates the library server 120 to reflectchanges in the object servers 130. If the user request is to retrieve anobject, the object identification system 140 executes the request toretrieve an object. Then, in block 270, the object identification system140 may remove the element from the element table after the userfinishes manipulating the object (e.g., opening the object, viewing it,and closing it). Following is a more detailed description of the presentinvention.

1. Receiving Request To Manipulate Object

[0040] The user submits and the client computer 110 receives a requestto manipulate an object.

2. Generating Unique Identifier For Each Request To Manipulate Object

[0041] After a request to manipulate an object is received by the clientcomputer 110, the client computer 110 generates a unique identifier foreach request to manipulate an object.

2.A. Client Computer and Element Handle Characteristics

[0042]FIG. 2 is a block diagram illustrating one possible configurationof the client computer 110 utilized by the object identification system140. Typically, there is a single client computer 110. However, thoseskilled in the art will recognize that various client computer 110configurations, including multiple client computers 110 with appropriatecommunications, may also be utilized. The client computer 110 acts asthe user interface to utilize the triangular communications system.

[0043] The client computer 110 may be configured such that a portion ofmemory 300 is allocated to store one or more elements 310. Theseelements 310 may form an element table 320 (i.e., a row of the elementtable 320 corresponds to an element 310). Each element 310 occupies aspecific block of memory 300. An element handle 330 refers to the memoryaddress allocated to each element 310. As a default, the element table320 may be configured to store one hundred elements 310. Thus, onehundred element handles 330 or memory addresses are required to refer toone hundred elements 310. The number of elements 310 that may be storedwithin an element table 320 is limited by the available client computermemory 300 and/or memory allocated to the element table 320. If morethan one hundred elements 310 are required, the user can configure theclient computer 110 to allocate additional memory 300 to the elementtable 320, if available, to accommodate additional elements 310.

[0044] Further, each element 310 is populated by related object data340. In addition, the client computer 110 includes a daemon process 350.The daemon process 350 manages the requests submitted by the user andacts as an interface between the client computer 110, library server120, and object server 130. In addition, the client computer 110includes a file system 360 to which objects may be retrieved from anobject server 130.

[0045] The unique identifier for all requests, whether the request is tostore an object or to retrieve an object, is the element handle 330,which refers to the memory address of the element 310, generated foreach request. Thus, each request is assigned a unique element handle 330since an element 310 is generated for each request, and each element 310is referenced by a specific memory address. Thus, the element handle 330serves as a pointer to each element 310 within the element table 320.For example, if a user submits a request to store an object, the memoryaddress allocated to the element 310 generated for that store request isthe element handle 330. Similarly, when a user submits a request toretrieve an object, the memory address of the element 310 generated forthat retrieve request is the element handle 330. Thus, an element handle330 is assigned to individual requests rather than individual users orapplications. Each user or application may submit multiple requests, andeach request is assigned a unique element handle 330 which refers to thememory address allocated to the element 310 and related object data 340.

[0046] Having the ability to uniquely identify each request to store orretrieve an object allows application programs to distinguish copies ofobjects from each other and to distinguish a copy of an object from theoriginal object. Multiple tasks involving the same object may beexecuted simultaneously or in parallel rather than in serial orsequential order. In other words, each process thread can manipulate anobject without waiting for the previous thread to execute, andtherefore, the application process will be executed in less time.Distinguishing requests to manipulate larger multimedia objects is evenmore advantageous. Multimedia objects require significantly more time toprocess compared to traditional digital text and numerical data sincethey are much larger than text and numerical objects. Therefore,identifying each request to manipulate an object with an element handle330 increases efficiency.

2.B. Structure Of Elements, Element Handles, and Element Table Memory

[0047] Each element 310 of the element table 320 may be populated byobject data 340. For clarity, the specification and figures will referto storing data to an element 310 as “populating” an element 310 withobject data 340, whereas storing an object from memory or from a file toan object server will be referred to as “storing” an object.

[0048] An element 310 may be populated with object data 340 that assumesdifferent data structures. In one embodiment of the present invention,object data 340 may be defined as the following structure: typedefstruct { POPENLIST pOpenList; // pointer to open list node STORETYPEStoreType; // storage type (e.g., memory or  file) PVOID pStorage; //pointer to memory or to  filename ULONG ulLength; // element lengthELEMKEY szKey; // element key ULONG ulLengthCurrent; // current length .. . } CLNTOPENELEM;

[0049] The pOpenList data field is a pointer that refers to an open listnode or to a list of other pointers. An open list node is a set ofgeneral, persistent data about the environment, which is maintainedregardless of element 310 additions, deletions, and modifications.

[0050] The StoreType data field is used with both a request to store anobject and a request to retrieve an object. In the case of a request tostore an object, the daemon process 350 uses StoreType to determine theorigin of an object. In other words, the daemon process 350 usesStoreType to determine whether the object stored from a file or memory.In the case of a request to retrieve an object, the daemon process 350uses StoreType to determine the future location of an object. In otherwords, the daemon process 350 determines whether an object is retrievedto a file or to memory. In both requests to store an object and requeststo retrieve an object, StoreType indicates that the object is to bestored from or retrieved to memory if there is no resident memory tostore an object.

[0051] The pStorage data field is a pointer to the name of the file or apointer to a memory address identifying the object, depending on whetherstore type is file or memory.

[0052] The data field ulLength refers to the actual length of theobject.

[0053] The field szKey is an element key that identifies elements 310based on particular features or attributes. For example, szKey may referto an item identification, part number, and rep type. These threeidentification attributes are explained in further detail in section 3.

[0054] The field ulLengthCurrent is another status field that indicateswhat portion of an object has been retrieved. Typically, this field isuseful when retrieving very large objects. The field ulLengthCurrent maychange depending on what portion of the object has been retrieved. Thefield ulLengthCurrent will be the same as ulLength after an object hasbeen retrieved.

[0055] Furthermore, the ellipses in the structure indicate that otherfields may be included.

[0056] Thus, while the previously described data fields may be used togenerate elements 310, other alternative embodiments of the presentinvention may utilize one or more or all of the previously describeddata fields. Further, additional alternative embodiments may utilize oneor more of the following data fields (e.g., lRetention, pDescription,ulDescLength, bIsLibraryClientHandle, pEvent, TimeAvailable, bAsync,bAbort, ulLengthTarget, tid, ulExtRC, etc.) to generate object data 340to populate elements 310. Those skilled in the art will recognize thatother data fields may likewise be utilized to generate object data 340.

[0057] In one embodiment of the present invention, the following is asample element table 320 containing elements 310: Element Table ulLengthpOpenList StoreType pStorage ulLength szKey Current Element ElementpOpenList StoreType pStorage ulLength szKey ulLength Handle 1 1 1 1 1Current 1 => 1 Element Element pOpenList StoreType pStorage ulLengthszKey ulLength Handle 2 2 2 2 2 Current 2 => 2 . . . . . . . . . . . . .. . . . . . . . . . . Element Element pOpenList StoreType pStorageulLength szKey ulLength Handle n n n n n Current n => n

[0058] Each individual element 310 maybe illustrated as a row of objectdata 340. Each data field of the object data 340 may be represented as acolumn. For example, element 1 may be populated with pOpenList,StoreType 1, pStorage 1, etc. and element 2 may be populated withpOpenList, StoreType 2, pStorage 2, etc. Each element 310 and therelated object data 340 generated for each request to store or retrievean object is stored in a specific block of memory 300. The location ofeach block of memory 300 storing the element 310 and related object data340 is designated with a particular memory address, i.e, the elementhandle 330. Thus, the element handle 330 uniquely identifies and pointsto each element 310 (i.e., each row of object data 340) generated foreach request to manipulate an object.

3. Populating Elements With Object Data

[0059] The element handle 330 points to an element 310 populated withobject data 340 describing or identifying the object. For example, aspreviously described in section 2.B., the szKey data field may provideidentification data.

[0060] With reference to FIG. 4, the object data 340 and the source ofthe object data 340, may depend on whether the request is to store anobject or to retrieve an object (block 400). In a request to store anobject, the object identification system 140 proceeds to block 410.Otherwise, the object retrieval system proceeds to block 440.

[0061] In block 410, the object identification system 140 is handling arequest to store an object. Continuing with block 420, the element 310referenced by element handle 330 is populated with the current ororiginal memory address of the object within the client computer 110. Inother words, the element handle 330 refers to object data 340 indicatingthe location within a client computer 110 from which the object will betransferred. Since the object is resident in memory 300, this data maybeprovided by a user or a client computer 110 configured to provide thisdata.

[0062] In addition, an element 310 may be populated with object data 340indicating the size of an object in block 430. When the request is tostore an object, a user already possesses the object which may beresident on a client computer 110. Thus, the user may be able todetermine the size of an object, and this data may be entered into anobject data field of an element 310. Alternatively, the size data may begenerated by the client computer 110 if the client computer 110 isconfigured to read the object, determine the size of the object, andpopulate an element 310 with size data. Thus, in a request to store anobject, size data may be supplied by a user or a client computer 110.

[0063] In block 440, the request is to retrieve an object. Continuingwith block 450, the element 310 referenced by element handle 330 ispopulated with the future location with the client computer 110 of theobject. In other words, the location data indicates memory 300 withinthe client computer 110 which will store the retrieved object. Sincethis memory address is accessible to the user and the client computer110, this data may also provided by the user or the client computer 110.

[0064] Continuing with block 450, the element 310 referenced by theelement handle 330 is populated with size data relating to the object.When a user wants to retrieve an object, the object is stored in anobject server 130 rather than in resident memory of the client computer110. Thus, neither the user nor the client computer 110 has access todata indicating the size of the object to be retrieved. The user orclient computer 110 may determine that the object resides in aparticular object server 130 if there is only one object server 130.However, the user or client computer 110 may not know the memory addressof the requested object within that object server 130. Further, if thereare multiple object servers 130, the user or client computer 110 may notknow which object server 130 stores the requested object, much less thememory address of the object within a server 130. Thus, the user and/orclient computer 110 may not be able to determine the size of an objectwhich is to be retrieved. Consequently, object size data is transferredfrom the object server 130 to the client computer 110 by referring tothe element handle 330 and related object data 340. A more detaileddescription of this process is provided in section 6.B.

[0065] In block 470, in cases involving both a request to store anobject and to retrieve an object, element 310 may also be populated withidentification data. Typically, in block 470, an object is identified bya character string representing an item number and a part number. Ifnecessary, in block 480, the character string may also include a reptype attribute. These three fields makeup a unique key for objectsstored in the object server.

[0066] The item number represents or identifies the object itself. Thepart number represents components or pieces of the object as compared tothe whole object. The rep type, however, does not represent an object ora component of an object. Rather, the rep type describes the nature ofthe object or an object component. To describe the identificationattributes with an analogy, an “item number” may represent a document ora report, a “part number” may represent portions of that document suchas a paragraph or an illustration, and the “rep type” may describe thenature of an item or part as text or an image.

[0067] The primary identification attributes of an object are the itemnumber and part number. For example, if two objects are differentobjects if they are identified with different item numbers or partnumbers. If two objects are assigned the same item number and partnumber, then these two objects may still be differentiated by the reptype attribute even though the rep type describes or labels portions ofan object. Consequently, if an object is stored with the rep typeattribute, the request to retrieve that object must also indicate therep type to distinguish two objects with the same item number and partnumber. However, if an object is stored without the rep type attribute,a placeholder is assigned to the rep type variable. A placeholderindicates that no rep type was designated. In this case, it is notnecessary to designate the rep type when a request to retrieve thatobject is submitted by a user.

4. Transfer Element Handle To Library Server

[0068] Continuing with FIG. 2, having discussed the configuration of thesystem utilized by the object identification system 140, the objectidentification system 140 transfers the element handle 330 to a libraryserver 120 in block 230. More specifically, the element handle 330 istransferred from the client computer 110 to the library server 120 bythe daemon process 350 after the element 310 is populated with objectdata 340. The daemon process 350 performs the administrative task ofmanaging the memory queue of the client computer 110. After an element310 is generated, the element handle 330 is transferred into a memoryqueue of the client computer 110. The daemon process 350 periodicallyscans the memory queue of the client computer 110. When a new elementhandle 330 has been placed in the queue indicating that a user hasrequested to manipulate or store an object, the daemon process 350forwards the element handle 330 to the library server 120. Uponreceiving the element handle 330, the library server 120 may also checkthe object data fields populating the element 310 for errors andinconsistencies before the library server 120 selects an object server130 and transfers the element 310 to the selected object server 130. Theobject identification system 140 then continues to block 240.

[0069] In block 240, the element handle 330 is transferred to the objectserver 130 selected by the library server 120. The manner in which theelement handle 330 is transferred with respect to requests to store(block 250) and requests to retrieve (block 260) objects will beexplained in further detail below with reference to FIGS. 5 and 6.

5. Executing Request To Store Object

[0070]FIG. 5 is a flow diagram illustrating how the objectidentification system 140 executes a request to store an object in anobject server 130.

[0071] In block 500, the child process of the selected object server 130receives the element handle 330 from the library server 120. In oneembodiment in a request to store an object, in order to select an objectserver 130, the library server 120 consults a directory of the contentsof each object server 130 (i.e., a catalogue) to determine which objectserver 130 has room to store the object and selects this object server130. Then, the library server 120 transfers the element handle 330 tothe selected object server 130. The object server catalogue may beresident in the library server 120 and may be updated to reflectadditions, deletions, and modifications of objects within an objectserver 130.

[0072] In an alternative embodiment, the library server 120 determineswhether any object server 130 already stores the particular object andprocesses the store request only if the object to be stored is differentfrom the object already in the data store. Based on a review of thecatalogue, if the object server 130 does not currently store therequested object, the library server 120 then determines whether thatobject server 130 contains sufficient memory to store the object. Ifsufficient memory may be allocated, the library server 120 may selectthat object server 130 and transfer the element handle 330 to theselected object server 130. However, if an object server 130 alreadystores the requested object, the library server 120 may transmit amessage to the user and/or client computer 110 indicating that therequest to store the object is not necessary since the object server 130already contains the object. Further, if no object server 130 containssufficient memory, the library server 120 may transmit a message to theclient computer 110 and/or user indicating that there is insufficientmemory to store this object.

[0073] The following alternative embodiments illustrate various othertechniques to ascertain the contents of each object server 130 todetermine which object server 130 will be selected by the library server120. In an alternative embodiment, the library server 120 mayperiodically scan each object server 130 and update the object serverdirectory to reflect any changes. In yet another alternative embodiment,the user may update the object server directory stored on the libraryserver 120 after the user's request to manipulate an object has beencompleted. It is apparent to one of ordinary skill in the art thatnumerous techniques may be implemented to provide the library server 120with current data regarding which objects reside in particular objectservers 130.

[0074] In block 510, after the object server 130 receives the elementhandle 330, the element handle 330 is transferred from the selectedobject server 130 to the client computer 110.

[0075] In block 520, the daemon process 350 checks the element handle330 to determine whether the element handle 330 is valid and correspondsto the correct object. After receiving the element handle 330 from thelibrary server 120, the object server 130 has established communicationswith the client computer 110 and identified itself to the clientcomputer 110 as the object server 130 that will store the object. Ifafter checking the element handle 330 the daemon process 350 determinesthat the element handle 330 is not valid, then the daemon process 350may post an error to the client computer 110 and/or the user. If theelement handle 330 is valid, the daemon process 350 continues with therequest to store an object by transferring object data 340 to theselected object server 130.

[0076] In block 530, if the request is to store to memory, the childprocess of the object server 130 determines the size of the object fromthe object data 340 and allocates sufficient memory within the objectserver 130 to store the object. In block 540, if the request is to storeto a file, then the child process stores directly to the file, withoutallocating memory.

[0077] Continuing with block 550, a copy of the object is generated andplaced in the output queue of the client computer 110. Alternatively, asnecessary, the user and/or the client computer 110 may make additionalcopies of the object before storing the object to the object server 130.For example, working and/or reference copies of the object may begenerated.

[0078] In block 560, the object is then manipulated. As previouslydefined, an object is manipulated by transferring the object from theclient computer 110 to the object server 130. When the selected objectserver 130 receives the object, the child process may direct the objectto the allocated memory. In an alternative embodiment, the object may betransferred to the object server 130, and after the object server 130receives the object, the child process can determine the size of theobject, allocate sufficient memory, and store the object to theallocated memory. After the object has been manipulated, the objectserver 130 receiving the object may update the directory of the contentsof each object server 130 which is stored in the library server 120 toreflect the addition of an object.

6. Executing Request To Retrieve Object

[0079] With reference to FIG. 6, a flow diagram illustrating how theobject identification system 140 executes a request to retrieve anobject, in block 600, an object server 130 receives an element handle330 from the library server 120.

[0080] In one embodiment in a request to retrieve an object, in order toselect an object server 130, the library server 120 scans the catalogueto determine which object server 130 stores the object. In particular,the catalogue specifies the content of each object server 130. If anobject server 130 stores a requested object, the library server 120selects that object server 130 and transfers the element handle 330 tothe selected object server 130.

[0081] In an alternative embodiment, for a request to retrieve anobject, the library server 120 scans the directory of the contents ofeach object server 130. The library server 120 determines which, if any,object server 1300 already stores the requested object. If an objectserver 130 stores a requested object, the library server 120 selectsthat object server 130 and transfers the element handle 330 to theselected object server 130. However, if the library server 120 can notlocate the requested object in any object server 130, then the libraryserver 120 may inform the client computer 110 and/or the user that therequest can not be executed and the application will fail.

[0082] The following alternative embodiments illustrate various othertechniques to ascertain the contents of each object server 130 todetermine which object server 130 will be selected by the library server120. In an alternative embodiment, the library server 120 mayperiodically scan each object server 130 and update the object serverdirectory to reflect any changes. In yet another alternative embodiment,the user may update the object server directory stored on the libraryserver 120 after the user's request to manipulate an object has beencompleted. It is apparent to one of ordinary skill in the art thatnumerous techniques may be implemented to provide the library server 120with current data regarding which objects reside in particular objectservers 130.

[0083] Continuing with block 610, the element handle 330 is thentransferred from the selected object server 130 to the client computer110.

[0084] In block 620, In block 520, the daemon process 350 determines thevalidity of the element handle 330 and whether the element handle 330corresponds to the correct object. At this point, the object server 130has established communications with the client computer 110 andidentified itself to the client computer 110 as the object server 130that will supply the object to the client computer 110. If the elementhandle 330 is not valid, the daemon process 350 may post an error to theclient computer 110 and/or the user. If the element handle 330 is valid,the daemon process 350 continues with the request to retrieve an objectby requesting that the object server 130 transfer the object size datato the client computer 110. If the request is to retrieve the object tomemory, the object identification system 140 proceeds to block 630.Otherwise, the object identification system 140 proceeds to block 640.

[0085] In block 630, if the request is to retrieve to memory, the daemonprocess 350 of the client computer 110 determines the size of the objectfrom the object size data and allocates sufficient memory 300 within theclient computer 110 to store the object. In block 640, if the request isto store to a file, the daemon process 350 stores directly to the filein the file system 28, without allocating memory. The client computer110 is then prepared to receive the object, and the object server 130 isprepared to transfer the object.

[0086] Continuing with block 650, the child process of the selectedobject server 130 generates a copy of the object. Then in block 660, thecopy is placed in the output queue of the object server 130 andmanipulated. In a request to retrieve an object, an object ismanipulated by transferring the requested object from the selectedobject server 130 to the client computer 110. When the object isreceived by the client computer 110, the object is stored in theallocated memory or a file. The user may then access the object andcopy, modify, transfer, and/or utilize the object as necessary. In analternative embodiment, a single object server 130 may be coupleddirectly to a user operating on a separate workstation, and the objectserver 130 may transfer the object directly to the user rather thandirecting the object through the client computer 110.

[0087] After the object has been manipulated, the object server 130receiving the object may update the directory of the contents of eachobject server 130, if necessary (which is stored in the library server120), to reflect that an object was added, deleted, or updated at theobject server 130. For example, if a thread requires a copy of anobject, the contents of the object server 130 do not change since theoriginal object remains stored in the object server 130. If the objectis updated/deleted in the object server 130, then content of the objectserver 130 has changed and the directory of the contents of each objectserver 130 stored in the library server 120 must be updated.

6.C. Updating Library Server After Manipulating Object

[0088] After an object has been manipulated, the directory of objectservers 130 maintained by the library server 120 may need to be updatedto reflect the addition, deletion, or any other change of an object froman object server 130. More specifically, the object server 130 involvedin manipulating an object updates the directory corresponding to thatobject server 130 to indicate that a new object has been added, deleted,or otherwise changed. Alternatively, the library server 120 mayperiodically scan the contents of each object server 130 and update thedirectory to reflect any changes within the object servers 130. In yetanother alternative embodiment, the user may update the library server120 directory. For example, the user may confirm that the object wassuccessfully stored in the object server 130 by retrieving the objectand update the library server 120 if the user knows the memory addresswithin the object server 130 corresponding to that object.

[0089] Furthermore, after an object has been manipulated and the libraryserver 120 has been updated, if necessary, the element 310, elementhandle 330, and related object data 340 may be removed from the elementtable 320.

7. Deleting Element Handle From Element Table

[0090] Continuing with FIG. 2, in block 270, after the object ismanipulated, the object identification system 140 may remove an element310 from the element table 320 to free memory 300 for other elementsgenerated by new requests. However, with reference to FIG. 7, a flowdiagram illustrating when an element 310 is removed in requests to storeand to retrieve an object, the time when elements 310 may be removeddepends on the request as shown in block 700. If the request is to storean object, the object identification system 140 proceeds to block 710.Otherwise, the object identification system 140 proceeds to block 740.

7.A. Deleting Element Handle After Storing Object

[0091] In block 710, the user request is to store an object. In thiscase, whether the element 310 may be removed from the element table 320depends on whether the object has actually been stored in the selectedobject server 130 as shown in block 720. If the object is stored in thecorrect object server 130, then the element 310 may be deleted from theelement table 320. However, in block 730, if the object has not beenstored in the selected object server 130, or was stored in the incorrectobject server 130, then the user and/or client computer 110 must waituntil the object is stored in the selected object server 130. Then, theelement 310 may be deleted from the element table 320.

7.B. Deleting Element Handle After Retrieving Object

[0092] In block 740, the user request is to retrieve an object. In thiscase, as shown in block 750, whether the element 310 may be deletedafter a request to retrieve an object depends on whether the user and/orclient computer 110 has finished manipulating the object. In block Ifthe object has been manipulated, then the element 310 may be removedfrom the element table 320. However, in block 760, if the object isstill being manipulated by the process thread or will be manipulated bya thread in the future, then the element 310 can not be deleted untilthe manipulation has been completed. After the process thread hasexecuted and the object is no longer needed by the thread, the element310 may be deleted from the element table 320.

Asynchronous Object Retrieval In Multimedia Library

[0093] Another embodiment of the present invention provides an objectaccess system 150. The object access system 150 allows users to accessobjects while they are being transferred and releases processes thatwere allocated to the object transfer after the transfer has beeninitiated such that those processes may be utilized for other tasks.

[0094]FIG. 8, a flow diagram illustrating the technique of the objectaccess system 150, generally illustrates how requests to retrieveobjects are processed asynchronously and how those requests areprocessed among a client computer 110, library server 120, data storesor object servers 130. The object access system 150 utilizes a clientcomputer 110 configuration similar to that illustrated in FIGS. 1(A-C)and 3. The client server 110 includes a daemon process 360 that operatesin the background to facilitate access and retrieval of objects from anobject server. The daemon process 360 manages or “catches” the requestssubmitted by the user and acts as an interface among the client computer110, library server 120, and object server 130.

[0095] Initially, in block 800, the object access system 150 receives arequest from a client process at a client server 110 to access orretrieve an object stored in an object server 130. In block 810, theobject access system 150 allocates a library server process to processthe object request. Then, in block 820, the object access system 150locates the requested object within an object server 130. In block 830,the object access system 150 initiates the transfer of the requestedobject from the object server 130 under control of the library serverprocess to the daemon process 360. Then, in block 840, the object accesssystem 150 notifies the selected object server 130 that the objecttransfer has been initiated. In block 850, the object access system 150releases the library server process that was allocated to handle theobject request. The object access system 150 then transfers control tothe user in block 860. Finally, in block 870, the object access system150 transfers the object from the daemon process 360 to the clientserver 110. Following is a more detailed description of the presentinvention. For clarity, the following description refers to the actualcomputer, server or process (e.g., library server 120 or daemon process360) as performing a task even though the same tasks may be consideredto be performed by the object access system 150.

[0096] Initially, in block 800, with reference to FIGS. 1(A-C), a usersubmits a request for an object at a client computer 110 which ishandled by a client process of client computer 110. The request may besubmitted through, for example, an Application Program Interface set or“API” set associated with or residing in client computer 110. An API isa set of routines and protocols for building software applications. Inother words, an API enables programs to be developed more easily byproviding an interface through which components of the program can beutilized. Those skilled in the art will recognize that objects may berequested through various user interfaces. The request is thentransferred from a client computer 110 to the library server 120.

[0097] In block 810, the library server 120 allocates a library serverprocess, such as a child process, to process the object request. Alibrary server process such as a child process executes commands orprograms relating to the library server 120 such as locating an objectserver 130 and authorizing the transfer of an object from an objectserver 130 to a client server 110. The request for an object is sentfrom the client server 110 to the library sever 120 through, forexample, a communications isolator or some other communications link orsystem. The request is then sent from the library server 120 to anobject server 130 through the communications isolator.

[0098] In block 820, the allocated library server process locates therequested object within an object server 130 through, for example, adirectory stored in the library server 120. Continuing with block 830,the object server 130 selected by the library server process initiatesthe transfer of the requested object from the object server 130 undercontrol of the library server process to a daemon process 360 of clientserver 110. After transferring the object to the daemon process 360, inturn, the daemon process 360 transfers the object to the client server110.

[0099] In block 840, after the transfer of the requested object has beeninitiated, the daemon process 360 confirms with the object server 130that the object transfer has begun. The following is provided as anexample structure that is sent by the daemon process 360 to objectserver 130 to acknowledge that the daemon process 360 has startedreceiving the object from the object server 130 (i.e., object transferhas begun): typedef struct { ISOMSGHDR IsoMessageHeader;LS_GENERIC_HEADER lsHeader; rsStoreID achBlobServer; rsSubStoreIDachBlobSubstore; ULONG ulRowsAffected; LONG 1CacheCode; LONG 1BlobCode;LONG 1AccessMethodCode; LONG 1AccessMethodFailureCode; LONG1TargetBlobCode; LONG 1TargetAccessMethodCode; LONG1TargetAccessMethodFailureCode; LONG 1LibraryServerCode; LONG 1SQLCode;SHORT sSQLNumber; clock_t ulTimeClientFromBlob; clock_tulTimeClientToBlob; ULONG ulImageLength; } DMN_STORE_RETRIEVE_CO;

[0100] In the above structure, the field achBlobServer stores an objectserver name. The fields 1CacheCode, 1BlobCode, 1AccessMethodCode,1AccessMethodFailureCode, 1 TargetBlobCode, 1TargetAccessMethodCode,1TargetAccessMethodFailureCode, 1LibraryServerCode, 1SQLCode, sSQLNumberstore return codes (e.g., zero may indicate success, while other valuesindicate errors). The field ulTimeClientFromBlob stores a time at whichthe daemon process 360 gets an indication that retrieval has beeninitiated. The field ulTimeClientToBlob stores a current time when thedaemon process 360 is replying back to the object server 130. The fieldullmageLength stores the length of the object being transferred.

[0101] The daemon process 360 may confirm with the object server 130that the object transfer has begun at various times. For example, in oneembodiment of the invention, the daemon process 360 sends theconfirmation to the object server 130 immediately after the transfer isinitiated. In an alternative embodiment of the present invention, thedaemon process 360 confirms with the object server 130 that objecttransfer has been initiated at any time during the transfer of therequested object. Those skilled in the art will recognize that thedaemon process 360 may send the confirmation to the object server 130any time after the transfer has been initiated.

[0102] In block 850, the object server 130 releases the library serverprocess from the object transfer, and control of the library serverprocess is returned to the library server 120. The following is providedas an example structure that is sent from the object server 130 to thelibrary server 120 to release a library server (“child”) process that ishandling the retrieve order: typedef PACKED struct {RS_GENERIC_HEADER  rsHeader; RS_GENERIC_RESPONSE rsResponse; rsItemIDachitem; rsRepType achversion; rsPartNum ulpart; rsSemType sSemType;rsItemID achfolderid; rsPatronID achownerid; rsBoolean bcache_current;rsTimeStamp achreferenced; rsTimeStamp achchanged; rsTimeStampachoptimistic; rsTimeStamp achcreated; rsDays ulexpires; rsSecCodebseclabel; rsStoreHint achstorehint; rsLength ullength; rsOsIDachOS_identifier; rsLocCode blocation_kind; VCHAR vcext_type; VCHARvcprovenance; VCHAR vclabel; VCHAR vclocation; } RETRIEVE_RESPONSE;

[0103] As a result, the library server process that was previouslyallocated to the object transfer is no longer bound to that objecttransfer task. Thus, in contrast to conventional systems, the libraryserver process may be allocated to other tasks while the requestedobject is being transferred to the daemon process 360 and client server110. In other words, requests for objects are executed asynchronously orindependently of when other object transfers have completed. Thisenhancement is beneficial since the library server process may beutilized to process other requests, increase throughput, and enhancesystem performance.

[0104] In block 860, after the library server 120 regains control of thelibrary server process, the daemon process 360 may return control to theuser via the client computer 110. A user may regain control at varioustimes to perform various tasks. For example, in one embodiment of thepresent invention, the user can obtain control almost immediately afterthe transfer has been initiated. In other words, control may be returnedto a user almost immediately after an object retrieval API has beencalled. In another embodiment of the present invention, the user mayassume control at any time during the object transfer. In yet anotheralternative embodiment, the user can also choose to retrieve the entireobject before the user regains control by using options known to thoseskilled in the art. For example, the user decide to invoke options ofthe fOpenControl parameter of the SimLibOpenObject API which may includeSIM_OPEN_DISK or SIM_OPEN_MEMORY such that control is returned to theuser after the entire object is retrieved. Thus, as illustrated in FIG.3, the user may regain control before the object has been transferredfrom the daemon process 360 to the client computer 110. Alternatively,control may be returned to the user after the object transfer has beeninitiated.

[0105] The following is an example of the fOpenControl parameter of theSimLibOpenObject API for one embodiment of the invention:

[0106] BITS—input

[0107] Control option bits for opening the object. The following arevalid values:

[0108] SIM_OPEN_DISK

[0109] Opens the object on disk. This value is the default; if thisvalue is used, it will simultaneously increase application performanceand decrease memory usage. This value will also use the pszFileLocationparameter. A user will not regain control until the whole object hasbeen retrieved from the object server.

[0110] SIM_OPEN_MEMORY

[0111] Opens the object in memory. If this value is used, the systemwill not use the pszFileLocation parameter. The user will not regaincontrol until the whole object has been retrieved from the objectserver.

[0112] SIM_OPEN_DISK_ASYNC

[0113] Opens the object on disk asynchronously. Once the object beginstransferring from the object server, the user will regain controlimmediately. Exceptions: If the access level (ulAccessLevel) valueequals SIM_ACCESS_READ_WRITE, this option will be treated the same asSIM_OPEN_DISK. Also, for MAXPIECE objects, SIM_OPEN_DISK_ASYNC willbehave like SIM_OPEN_DISK.

[0114] SIM_OPEN_MEMORY_ASYNC

[0115] Opens the object in memory asynchronously. Once the object beginstransferring from the object server, the user will regain controlimmediately. Exceptions: If the access level (ulAccessLevel) valueequals SIM_ACCESS_READ_WRITE, this option will be treated the same asSIM_OPEN_MEMORY. Also, for MAXPIECE objects, SIM_OPEN_MEMORY_ASYNC willbehave like SIM_OPEN_MEMORY.

[0116] After obtaining control, the user/client computer 110 may performvarious tasks. The following examples are used only for illustrativepurposes. In one embodiment of the present invention, the user mayaccess, process or utilize any portion of the retrieved object as theobject is being transferred from the client server 110 via the daemonprocess 360.

[0117] In another embodiment, the user may exercise control byidentifying what portion of the requested object has been transferred,i.e., how many bytes of the object has been transferred. As a result,the user can determine how many remaining bytes must be transferred, andbased on a transfer rate, how much additional time is required tocomplete the transfer.

[0118] For example, during asynchronous object retrieval, a user canfind out how many bytes have been transferred to the user at any momentby calling the Ip2QueryObjectAccess( ) API and using ulCurrentObjSizeand ulObjSize from an OBJACCINFOSTRUCT data structure. The following isan example Ip2QueryObjectAccess API function: ULONG SIMENTRYIp2QueryObjectAccess ( HSESSION hSESSION, // handle to a session // fromSimLibLogon HOBJACC hObjAcc, // Object access handle // fromSimLibOpenObject call PRCSTRUCT pRC); // pointer to return structure

[0119] The above API will return a data structure OBJACCINFOSTRUCT withthe pointer pRC→ulParam1. An example OBJACCINFOSTRUCT data structure isdefined as follows: // Object access information typedefstruct_OBJACCINFOSTRUCT {  ULONG ulStruct; // Size of the structure ULONG ulAccessLevel; // SIM_ACCESS_SHARED_READ (0) // orSIM_ACCESS_READ_WRITE (2)  ULONG ulOpenControl; // SIM_OPEN_DISK (0) or// SIM_OPEN_MEMORY (1)  ULONG ulObjSize; // Object size  char * pMemLoc;// Object memory location // if opened to memory  BOOL bUserHasFile; //Flag indicating user // called GetObjectFileName  OBJ Obj; // Objectdata structure  char szFileName // File path and name if [257]; //opened to disk  char szReserved [3]; // Not used  ULONGulCurrentObjSize; // Current retrieved size // so far for asyncretrieval  } OBJACCINFOSTRUCT, *POBJACCINFOSTRUCT;

[0120] From the above structure, ulObjSize is the total size of theobject, and ulCurrentObj Size is the current size that has beenretrieved. Callers of the Ip2QueryObjectAccess API can call this APImultiple times, if once is not enough, until the ulCurrentObjSizereaches the application's desired size. If the ulCurrentObjSize equalsulObjSize in the OBJACCINFOSTRUCT data structure, the retrieval hascompleted.

[0121] Further, in yet an additional alternative embodiment of thepresent invention, the user or client 110 may choose to abort thetransfer of the requested object before the whole object has beentransferred. For example, the object transfer may be aborted through theLibrary Client API LibFreeltemPart(pSession, IS_TRUE, hBlob), wherepSession is the Library Client logon session handle, and hblob is theelement handle of the object being retrieved. The LibFreeltemPart( )function is used to free a handle to an object in the cache or a handleto a response block The following is an example of the LibFreeltemPart(Free an Item Part) API:

[0122] LibFreeltemPart (pSession, bReclaim, hElement)

[0123] The pSession parameter is the handle to a library client sessionand receives input of SESSION_P.

[0124] The bReclaim parameter receives input of TRUE_FALSE and is anindicator for whether the library server should reclaim the data storagein the cache or retain the storage for later retrieval. The valid valuesare: IS_TRUE to abandon the data and reclaims the space or IS_FALSE tokeep the object in the cache, to be obtained later.

[0125] The hElement parameter has input of HELEMENT and is the handle tothe object in the cache.

[0126] On successful completion, the function returns one of thefollowing values: RC_OK LCERR_NULL_SESSION LST_ERR_ELEM_NOT_FOUND

[0127] To use the LibFreeItemPart function, if the object is stored ondisk, the user must close the disk file before using this function.Preferably, the application calls the function as soon as it finisheswith the object. In some environments (e.g., For Microsoft Windows 95®,Microsoft Windows NT®, and IBM AIX® environments) cache is implementedin workstation memory, rather than hard disk. In some environments(e.g., an IBM OS/2® environment) users can select cache to be eithermemory (no cache client) or hard disk (cache client).

[0128] In an additional embodiment of the object access system 150, theuser or client server 110 can decide whether the requested object willbe retrieved to memory 300 or to a file 360. If the object is retrievedto memory 300, the object access system 150 allocates a memory pointerreferring to the size of the final object length. In this case, as theobject is retrieved from the object server 130 through the daemonprocess 360 to the client server 110, the allocated memory 300 may befilled without changing the size of the allotted block of memory 300.

[0129] Alternatively, the user or client server 110 may decide toretrieve the object to a file 360. In this case, the file 360 can beopened with the final size of the final object length, and the objectcan be stored to the file 360 without change the file size.

[0130] Those skilled in the art will recognize that the user and/or theclient may perform various other tasks, and that the previous examplesare provided only for illustrative purposes.

Conclusion

[0131] This concludes the description of embodiments of the invention.The following describes some alternative embodiments for accomplishingthe present invention. For example, any type of computer, such as amainframe, minicomputer, or personal computer, or computerconfiguration, such as a timesharing mainframe, local area network, orstandalone personal computer, could be used with the present invention.

[0132] The foregoing description of embodiments of the invention havebeen presented for the purposes of illustration and description. It isnot intended to be exhaustive or to limit the invention to the preciseforms disclosed. Many modifications and variations are possible in lightof the above teaching. It is intended that the scope of the invention belimited not by this detailed description, but rather by the claimsappended hereto.

What is claimed is:
 1. A method of manipulating objects at a computer,the method comprising: receiving one or more requests to manipulate anobject, wherein each request is received from a different thread; foreach request, generating a copy of the object; and associating a uniqueidentifier with each request and its copy of the object to distinguishbetween requests that manipulate copies of the object.
 2. The method ofclaim 1, wherein the computer is connected to one or more data storesthrough an intermediate processing computer.
 3. The method of claim 2,wherein the intermediate processing computer selects one of the datastores.
 4. The method of claim 2, wherein the intermediate processingcomputer is updated to reflect changes within the data stores.
 5. Themethod of claim 1, wherein one of the requests to manipulate comprises arequest to store the object into a data store.
 6. The method of claim 5,wherein the computer is connected via a network to a library server andto one or more object servers and further comprising: transmitting therequest from the computer to the library server, wherein the requestincludes the unique identifier; at the library server, selecting anobject server; and transmitting the request to the object server,wherein the request includes the unique identifier; and at the objectserver, communicating with the computer to receive the object to bestored, using the unique identifier to identify the object.
 7. Themethod of claim 1, wherein one of the requests to manipulate comprises arequest to retrieve the object from a data store.
 8. The method of claim7, wherein the computer is connected via a network to a library serverand to one or more object servers and further comprising: transmittingthe request from the computer to the library server, wherein the requestincludes the unique identifier; at the library server, selecting anobject server; and transmitting the request to the object server,wherein the request includes the unique identifier; and at the objectserver, communicating with the computer to transmit the object to beretrieved, using the unique identifier to identify the object.
 9. Themethod of claim 1, wherein a different copy of the object exists foreach of the requests.
 10. The method of claim 1, wherein a first copy ofthe object is distinguished from a second copy of the object.
 11. Themethod of claim 1, wherein a first copy of the object is distinguishedfrom the original object.
 12. The method of claim 1, wherein more thanone request simultaneously manipulates a same object.
 13. The method ofclaim 1, wherein the unique identifier refers to a memory address. 14.The method of claim 13, wherein the unique identifier further comprisesa pointer referring to a set of object data.
 15. The method of claim 14,wherein the set of object data comprises a location of the object. 16.The method of claim 14, wherein the set of object data comprises anidentification of the object.
 17. The method of claim 16, wherein theidentification comprises an item number and a part number.
 18. Themethod of claim 17, wherein the identification further comprises a reptype.
 19. The method of claim 14, wherein the set of object datacomprises a size of the object.
 20. An apparatus for manipulatingobjects comprising: a computer; and one or more computer programs,preformed by the computer, for receiving one or more requests tomanipulate an object, wherein each request is received from a differentthread, for each request, generating a copy of the object, andassociating a unique identifier with each request and its copy of theobject to distinguish between requests that manipulate copies of theobject.
 21. The apparatus of claim 20, wherein the computer is connectedto one or more data stores through an intermediate processing computer.22. The apparatus of claim 21, wherein the intermediate processingcomputer selects one of the data stores.
 23. The apparatus of claim 21,wherein the intermediate processing computer is updated to reflectchanges within the data stores.
 24. The apparatus of claim 20, whereinone of the requests to manipulate comprises a request to store theobject into a data store.
 25. The apparatus of claim 24, wherein thecomputer is connected via a network to a library server and to one ormore object servers and further comprising: transmitting the requestfrom the computer to the library server, wherein the request includesthe unique identifier; at the library server, selecting an objectserver; and transmitting the request to the object server, wherein therequest includes the unique identifier; and at the object server,communicating with the computer to receive the object to be stored,using the unique identifier to identify the object.
 26. The apparatus ofclaim 20, wherein one of the requests to manipulate comprises a requestto retrieve data from a data store.
 27. The apparatus of claim 26,wherein the computer is connected via a network to a library server andto one or more object servers and further comprising: transmitting therequest from the computer to the library server, wherein the requestincludes the unique identifier; at the library server, selecting anobject server; and transmitting the request to the object server,wherein the request includes the unique identifier; and at the objectserver, communicating with the computer to transmit the object to beretrieved, using the unique identifier to identify the object.
 28. Theapparatus of claim 20, wherein a different copy of the object exists foreach of the requests.
 29. The apparatus of claim 20, wherein a firstcopy of the object is distinguished from a second copy of the object.30. The apparatus of claim 20, wherein a first copy of the object isdistinguished from the original object.
 31. The apparatus of claim 20,wherein more than one request wants to simultaneously manipulate a sameobject.
 32. The apparatus of claim 20, wherein the unique identifierrefers to a memory address.
 33. The apparatus of claim 32, wherein theunique identifier further comprises a pointer referring to set of objectdata.
 34. The apparatus of claim 33, wherein the set of object datacomprises a location of the object.
 35. The apparatus of claim 33,wherein the set of object data comprises an identification of theobject.
 36. The apparatus of claim 35, wherein the identificationcomprises an item number and a part number.
 37. The apparatus of claim36, wherein the identification further comprises a rep type.
 38. Theapparatus of claim 33, wherein the set of object data comprises a sizeof the object.
 39. An article of manufacture comprising a programstorage medium readable by a computer and embodying one or moreinstructions executable by the computer to perform method steps formanipulating objects at a computer, the method comprising: receiving oneor more requests to manipulate an object, wherein each request isreceived from a different thread; for each request, generating a copy ofthe object; and associating a unique identifier with each request andits copy of the object to distinguish between requests that manipulatecopies of the object.
 40. The article of manufacture of claim 39,wherein the computer is connected to one or more data stores through anintermediate processing computer.
 41. The article of manufacture ofclaim 40, wherein the intermediate processing computer selects one ofthe data stores.
 42. The article of manufacture of claim 40, wherein theintermediate processing computer is updated to reflect changes withinthe data stores.
 43. The article of manufacture of claim 39, wherein therequest to manipulate comprises a request to store the object into adata store.
 44. The article of manufacture of claim 43, wherein thecomputer is connected via a network to a library server and to one ormore object servers and further comprising: transmitting the requestfrom the computer to the library server, wherein the request includesthe unique identifier; at the library server, selecting an objectserver; and transmitting the request to the object server, wherein therequest includes the unique identifier; and at the object server,communicating with the computer to receive the object to be stored,using the unique identifier to identify the object.
 45. The article ofmanufacture of claim 39, wherein the request to manipulate comprises arequest to retrieve the object from a data store.
 46. The article ofmanufacture of claim 45, wherein the computer is connected via a networkto a library server and to one or more object servers and furthercomprising: transmitting the request from the computer to the libraryserver, wherein the request includes the unique identifier; at thelibrary server, selecting an object server; and transmitting the requestto the object server, wherein the request includes the uniqueidentifier; and at the object server, communicating with the computer totransmit the object to be retrieved, using the unique identifier toidentify the object.
 47. The article of manufacture of claim 39, whereina different copy of the object exists for each of the requests.
 48. Thearticle of manufacture of claim 39, wherein a first copy of the objectis distinguished from a second copy of the object.
 49. The article ofmanufacture of claim 39, wherein a first copy of an object isdistinguished from the original object.
 50. The article of manufactureof claim 39, wherein more than one request wants to simultaneouslymanipulate a same object.
 51. The article of manufacture of claim 39,wherein the unique identifier refers to a memory address.
 52. Thearticle of manufacture of claim 51, wherein the unique identifierfurther comprises a pointer referring to a set of object data.
 53. Thearticle of manufacture of claim 52, wherein the set of object datacomprises a location of the object.
 54. The article of manufacture ofclaim 52, wherein the set of object data comprises an identification ofthe object.
 55. The article of manufacture of claim 54, wherein theidentification comprises an item number and a part number.
 56. Thearticle of manufacture of claim 55, wherein the identification furthercomprises a rep type.
 57. The article of manufacture of claim 52,wherein the set of object data comprises a size of the object.
 58. Thearticle of manufacture of claim 52, wherein the set of object datacomprises a size of the object.
 59. A method of accessing objects in acomputer, the method comprising: receiving a request for an objectstored in an object server from a client process; allocating a libraryserver process to the object request; initiating a transfer of therequested object from the object server under control of the libraryserver process; and after initiating the transfer, releasing the libraryserver process from the object request.
 60. The method of claim 59,wherein the library server process comprises a child process of thelibrary server.
 61. The method of claim 59, wherein the requested objectis transferred from the object server to a daemon process to a clientserver, and wherein the daemon process confirms with the object serverthat the object transfer has been initiated.
 62. The method of claim 61,wherein the daemon process sends a confirmation to the object server atthe beginning of the transfer.
 63. The method of claim 61, wherein thedaemon process sends a confirmation to the object server while therequested object is being transferred.
 64. The method of claim 59,further comprising, after releasing the library server process,returning control to a user.
 65. The method of claim 64, furthercomprising allowing the user to access the partially transferred object.66. The method of claim 64, further comprising, after releasing thelibrary server process, performing other tasks with the library serverprocess while the requested object is being transferred.
 67. The methodof claim 59, further comprising identifying what portion of therequested object has been transferred.
 68. The method of claim 59,further comprising transferring the requested object to a file.
 69. Themethod of 68, further comprising transferring the requested object tothe file without altering the size of the file.
 70. The method of claim59, further comprising transferring the requested object to memory. 71.The method of 70, further comprising allocating a memory pointer in thefile with the size of the requested object.
 72. The method of claim 70,wherein an amount of memory allocated for the object is not altered whenthe object is transferred into memory.
 73. The method of claim 59,further comprising aborting the transfer of the requested object beforethe transfer has completed.
 74. The method of claim 59, wherein theentire object is retrieved before the process is released.
 75. Themethod of claim 59, further comprising receiving multiple requests forobjects, and wherein the requests are executed asynchronously.
 76. Anapparatus for manipulating objects comprising: a computer; and one ormore computer programs, preformed by the computer, for receiving arequest for an object stored in an object server from a client process;for allocating a library server process to the object request; forinitiating a transfer of the requested object from the object serverunder control of the library server process; and after initiating thetransfer, for releasing the library server process from the objectrequest.
 77. The apparatus of claim 76, wherein the library serverprocess comprises a child process of the library server.
 78. Theapparatus of claim 76, wherein the requested object is transferred fromthe object server to a daemon process to a client server, and whereinthe daemon process confirms with the object server that the objecttransfer has been initiated.
 79. The apparatus of claim 78, wherein thedaemon process sends a confirmation to the object server at thebeginning of the transfer.
 80. The apparatus of claim 78, wherein thedaemon process sends a confirmation to the object server while therequested object is being transferred.
 81. The apparatus of claim 76,further comprising, after releasing the library server process,returning control to a user.
 82. The apparatus of claim 81, furthercomprising allowing the user to access the partially transferred object.83. The apparatus of claim 81, further comprising, after releasing thelibrary server process, performing other tasks with the library serverprocess while the requested object is being transferred.
 84. Theapparatus of claim 76, further comprising identifying what portion ofthe requested object has been transferred.
 85. The apparatus of claim76, further comprising transferring the requested object to a file. 86.The apparatus of claim 85, further comprising transferring the requestedobject to the file without altering the size of the file.
 87. Theapparatus of claim 76, further comprising transferring the requestedobject to memory.
 88. The apparatus of 87, further comprising allocatinga memory pointer in the file with the size of the requested object. 89.The apparatus of claim 87, wherein an amount of memory allocated for theobject is not altered when the object is transferred into memory. 90.The apparatus of claim 76, further comprising aborting the transfer ofthe requested object before the transfer has completed.
 91. Theapparatus of claim 76, wherein the entire object is retrieved before thelibrary server process is released.
 92. The apparatus of claim 76,further comprising receiving multiple requests for objects, and whereinthe requests are executed asynchronously.
 93. An article of manufacturecomprising a program storage medium readable by a computer and embodyingone or more instructions executable by the computer to perform methodsteps for accessing objects at a computer, the method comprising:receiving a request for an object stored in an object server from aclient process; allocating a library server process to the objectrequest; initiating a transfer of the requested object from the objectserver under control of the library server process; and after initiatingthe transfer, releasing the library server process from the objectrequest.
 94. The article of manufacture of claim 93, wherein the libraryserver process comprises a child process of a library server.
 95. Thearticle of manufacture of claim 93, wherein the requested object istransferred from the object server to a daemon process to a clientserver, and wherein the daemon process confirms with the object serverthat the object transfer has been initiated.
 96. The article ofmanufacture of claim 95, wherein the daemon process sends a confirmationto the object server at the beginning of the transfer.
 97. The articleof manufacture of claim 95, wherein the daemon process sends aconfirmation to the object server while the requested object is beingtransferred.
 98. The article of manufacture of claim 93, furthercomprising, after releasing the library server process, returningcontrol to a user.
 99. The article of manufacture of claim 98, furthercomprising allowing the user to access the partially transferred object.100. The article of manufacture of claim 93, further comprising, afterreleasing the library server process, performing other tasks with thelibrary server process while the requested object is being transferred.101. The article of manufacture of claim 93, further comprisingidentifying what portion of the requested object has been transferred.102. The article of manufacture of claim 93, further comprisingtransferring the requested object to a file.
 103. The article ofmanufacture of 102, further comprising transferring the requested objectto the file without altering the size of the file.
 104. The article ofmanufacture of claim 93, further comprising transferring the requestedobject to memory.
 105. The article of manufacture of 104, furthercomprising allocating a memory pointer in the file with the size of therequested object.
 106. The method of claim 104, wherein an amount ofmemory allocated for the object is not altered when the object istransferred into memory.
 107. The method of claim 93, further comprisingaborting the transfer of the requested object before the transfer hascompleted.
 108. The method of claim 93, wherein the entire object isretrieved before the process is released.
 109. The method of claim 93,further comprising receiving multiple requests for objects, and whereinthe requests are executed asynchronously.